home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1996 March
/
EnigmA AMIGA RUN 05 (1996)(G.R. Edizioni)(IT)[!][issue 1996-03][Skylink CD IV].iso
/
earcd
/
assembler
/
progasm3.lha
/
UTILITY
/
StoneCr.doc
< prev
next >
Wrap
Text File
|
1995-03-04
|
6KB
|
119 lines
=-=-=-=-=-=-=-=-=-=-=-=> StoneCracker v4.10.3 <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Questo compattatore puo' comprimere eseguibili, dati, e anche programmi non
rilocabili, cioe' assemblati con "ORG" e "LOAD" a degli indirizzi assoluti
(fissi) e salvati con il WB (Write Binary) anziche' con il WO.
Decruncher per eseguibili: gli hunk (ossia le SECTION) sono compattati, poi
all'inizio del file viene "attaccato" il decruncatore e il rilocatore, che
provvedera' a scompattare gli hunk (data_C, code ecc.) e ad allocarli nella
memoria giusta. Fatto questo viene fatta partire la section code iniziale.
nota: le data e instruction cache sono azzerate prima di partire.
nota2: il file compattato e' autosuffuciente, non richiede la stc.library.
Data files - viene compattato il file, qualsiasi cosa contenga, e non e'
attaccato nessun decruncher.
Programmi ad ind. assoluti - Questo tipo di programmazione e' la peggiore
possibile al mondo, non fate mai programmi di questo tipo. Comunque per
comprimere uno di questi file occorre immettere questi dati:
Load - $xxxxx indirizzo dove scompattare il file, lo stesso dell'ORG & LOAD
Jump - $xxxxx da quale address far partire l'esecuzione, normalmente si
comincia dall'inizio, ma dipende da come avete organizzato la memoria
Ci sono 5 tipi di packmode, ossia di compressione. La piu' potente e' quella
a 16k, poi ci sono 8k, 4k, 2k, 1k. Conviene usare sempre quella a 16k, tranne
nei casi che il file da compattare sia piu' piccolo di 16k, in questo caso
puo' succedere che venga piu' corto il file con la compressione a 8k o 4k.
Questo numero e' la massima distanza di ricerca di stringhe uguali per la
compressione.
DataID - e' il suffisso che viene aggiunto alla fine dei file data compressi.
- In sostanza, l'uso di questo compattatore puo' essere di due tipi:
1) Compattare il file eseguibile salvato con "WO" da ASMONE, se questo file
non e' "immenso". Il problema e' che se un file, ad esempio, e' lungo
250Kb, e compresso viene 100Kb, per scompattarsi in memoria occorrono
ben 100Kb+250Kb, perche' deve essere caricato in memoria il file compresso
lungo 100Kb, e questo deve trovare altri 250Kb per "copiarci" il file
decompresso. Se il file deve scompattarsi su Amiga con 1Mb, occorre tener
conto del fatto che se fosse lungo 650Kb decompresso e 400Kb compresso,
occorrerebbero 650+400=1050Kb, e solitamente ne rimangono liberi per
un file circa 850-900!! Per quanto riguarda produzioni AGA, occorre
tener conto il limite dei 2MB, anziche' 1MB. La miglior scelta e' quella
di provare a compattare l'eseguibile con StoneCracker, e verificare se
si decompatta sul computer di base. Se non ce la fa, allora si deve optare
per il TitanCrunch, che e' piu' lento e meno efficiente, ma decomprime
5Kb alla volta, liberando man mano la memoria, e cio' permette la
decompressione di qualsiasi cosa.
2) Compattare dei dati, da caricare e decomprimere nel nostro programma.
A questo scopo, e' presente la routine di decompressione. Per usarla,
basta includerla nel nostro listato, ed eseguirla dandogli l'indirizzo
dove si trova la figura, la musica o quant'altro compresso in a1, e
l'indirizzo del buffer azzerato dove dovra' decomprimere i dati in a0:
LEA DEST,A0 ; DESTINATION ADDRESS
LEA CRUNC,A1 ; CRUNCHED DATA
BSR.W DECRUNCH
Vi sconsiglio vivamente di usare la compressione di file ad indirizzi assoluti
perche' non hanno futuro.
********* Documentazione originale sul formato del file compresso ***********
Decrunch info header & decrunching
Every file crunched with Stc4.02a or Stc4.10.3 has following header
(16 bytes) at the beginning of the crunched data:
"S404" or "S403" ; cruncher version - string
Security length ; overlap size - longword (security)
Original length ; decrunched length - longword
Crunched length ; crunched length - longword
. ; crunched data starts
.
.
Security length is always 16 + something.
There are also two control words at the end of crunched data. For
historical reasons it's quite wierd. I'll explain it with a
following picture:
<<- Lower memory Higher memory ->>
+------------ Crunched length ------------+
| |
InfoHeader|......................LastWord|BitCounter|MaxBits
^ ^ ^ ^
| | | |
Crunched data --+ | | |
| | |
Last crunched word --+ | |
| |
How many used bits there are in LastWord --+ |
|
Efficiency (packmode - only in S404) --+
If both crunched data and destination memory overlap there must
be atleast 'Security length' distance between the start of the
crunched data and the start of the destination memory:
<<- Lower memory Higher memory ->>
<<<-------------- Decrunching direction --------------
InfoHeader|......................LastWord|BitCounter|MaxBits
^
| |<------------ Destination memory starts here ....
| |
+-- SecLen ---+
|
+---------------> Crunched data starts here..